At 12:18 +0200 on 13/11/98, Kevin Heflin wrote:
> Yea, I did that, but I guess what I'm looking for, was that when ever
> anything was added to the table. Regardless of whether or not the
> spamblock was specified, it would be set to 'TRUE'
I guess adding constraints in alter statement is something to be placed in
Postgres's todo list if it is not there already.
But personally, I prefer doing this with "definition file" - SQL files
which define all the tables in my database.
In case of alteration, I dump all my tables and sequences, re-run the
creation file (which drops all tables and redefines everything), and reload
the tables and sequences - possibly adding data within the dump files to
reflect the addition or removal of columns.
This way, you can always recreate your database, create a second mirror, a
production database, etc. - and you can fill the "definition file" with
comments which will help you understand what you meant a year afterwards.
It's a tradition I kept from the time we used Oracle in one of my former
jobs. I think it's a practice taught in basic Oracle training, but it's
good for any database (that supports SQL/DDL scripts).
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
